home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group01a.txt
/
000007_icon-group-sender _Wed May 17 07:40:12 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2002-01-03
|
5KB
Return-Path: <icon-group-sender>
Received: (from root@localhost)
by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00581
for icon-group-addresses; Wed, 17 May 2000 07:39:57 -0700 (MST)
Message-Id: <200005171439.HAA00581@baskerville.CS.Arizona.EDU>
From: "Ian Trudel" <ian.trudel@tr.cgocable.ca>
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Wed, 17 May 2000 02:32:35 GMT
X-Complaints-To: abuse@cgocable.ca
X-Trace: carnaval.risq.qc.ca 958530755 24.226.208.172 (Tue, 16 May 2000 22:32:35 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
Content-Length: 4406
Hello Frank,
really interesting comments here.
> I would agree that it is much easier to add a new primitive type to the
Java
> implementation of Icon, as opposed to the C implementation. In either
case,
> however, adding a new primitive type involves coding in a language other
> than Icon. Ideally, it would be nice to be able to write a new type, along
> with its associated primitive operations, in Icon.
Yes, but there are many factors that may not be in favor of doing primitive
types in Icon. Speed issue may be a problem. Or when the primitive uses
system depend things, such as sockets or some database API. Yet, the spirit
of Icon is not "everything should be made in Icon" such as Smalltalk
communities. Icon is not even bootstrapped. This latter made me surprised,
Icon is so powerful and his text processing feature would just let anyone
write good, complete and yet understandable compiler/interpreter!
> Currently, Icon permits one to define a new type with a record
declaration,
> such as
>
> record Unicode_cset( ... )
>
> A programmer can then define procedures for the new record type. A record
> type, however, fails to extend the set of primitive types, for the
following
> reasons:
>
> 1. You cannot (re)define the primitive operators, such as "*", "++", or
> "<<", for a record type;
> 2. You cannot define implicit /explicit type conversions between a
record
> type and the existing types; and
> 3. You cannot define the behaviour of functions such as image and write
> for the new record type.
Good points here. I'm not sure it should be part of Icon programming
language though. It appears much more like "object orientation" than the old
procedural language style. (BTW, is it a feature of Idol? I never used it..)
To be honest, I'm not sure if it's a good idea to have primitive data type
ability at Icon's level. Primitive should be a limited resource. It would
also require much more work and I have no idea on the position of Icon
Project Group. Yet my intend is not to go against their vision and I do not
want to start a new dialect.
> Now imagine that we modify Icon so that we could define operators, type
> conversions, etc. for user-defined Icon types. Would this give us a
> "pluggable" capability, similar to Squeak?
Not exactly, but it'd be impressive as well. Actually, Squeak and Icon are
different in their nature. Squeak is a Smalltalk dialect. Smalltalk is a
pure object-oriented programming environment/language. Icon is not an
environment nor OO. Smalltalk is also bootstrapped. Smalltalk is written in
Smalltalk. Usually, the virtual machine is not in Smalltalk though. But here
comes Squeak, they're cheating!! The Squeak virtual machine is written in
Slang, a Smalltalk subset, and debugged under Squeak environment! It's just
awesome.. but it does not end here, because Squeak generate portable C code.
Did you guess? Yes, they're generating the virtual machine in C code and
compile it for virtually any plateforms!
Enough of Squeak/Smalltalk, let's talk about Icon again. Yes, that'd be nice
to write primitive in Icon. If we had a dynamic primitive data types system.
And no, we wouldn't have to change Icon's implementation for being able to
write primitive in Icon. Why? As I said earlier, Icon's text processing
features could just be great for compiler things. We could write a Icon to C
generator. I've seen a little thing provided with Icon (icn2c.icn, I think),
would not be too hard to extend it or rewriting it for that purpose.
Primitives could still be written in the old C way as well..
Anyway, I think adding dynamic primitive data type system would be valuable
at all points. IMHO, it'd be also acceptable for Icon Project Group, because
it doesn't require to change everything in their actual implementation. I
know they strive for some ultime stability and portability, which is great!
On the other hand, that would allow a faster evolution of Icon without
changing the base system, the work of Icon Project Group. Plus, if someone
like me does a new primitive data type and Icon Project Group likes it, this
could be easily integrated to the next release.. without redownloading the
whole Icon or even recompiling Icon *mega grin*.
PS: It'd be also nice to bootstrap Icon. Ok, ok, there's enough work to do
yet. ::))
--
Ian Trudel, aka BackOrder
StarTrip Server Administrator
http://startrip.gene6.com/